Bridging thc Gap Between Systems and C 1

cally for a given tim equation (ODE) softw an ordinary differential In addition to combinatorial gates, dynamic fault trees use four additional kinds of gates as modeling elements: Sequence Enforcing (SEQ), Functional Dependency (FDEP), Priority And (PAND), and Cold, Warm and Hot Spare (CSP, WSP and HSP). A SEQ gate asserts that component failures can occur only in the order specified by its inputs. An FDEP gate asserts that the failure of its frrst (trigger) input causes the immediate failure of the rest of its (dependent) inputs. A PAND gate indicates that a subsystem fails if the inputs to the gate fail in the specified order. CSP, WSP and HSP gates model primaryspare relationships. Each gate has a primary and one or more spare inputs. If the primary fails and if there are remaining spares, one is selected as the new primary; otherwise the subsystem represented by the gate fails. Using dynamic gates in conjunction with static gates enables the modeling of a wider range of systems than is possible with static gates alone. However, to have justified confidence in the results of a dynamic fault tree analysis, the analyst must have a clear understanding of the intended meanings of dynamic gates and dynamic fault trees composed from them, as well as trust in the software implementation of these constructs. The semantics can be specified in terms of a transformation that maps a given tree to an underlying semantic domain. In this case, we map a tree to a computerized numerical model amenable to solution by numerical analysis techniques. Because the mapping is complex, confidence in it demands that it be broken into an easy to understand composition of easy to understand intermediate representations and transformation steps. Beyond making the transformation understandable in the abstract, confidence in a tool requires trust in the software. Reliably developing flawless software remains beyond current software engineering capabilities. Thus errors remain a real risk. However, there are numerous important software engineering principles, the adherence to which can provide a justification for reasonable confidence in a software system. Perhaps the most important principle of all is to keep software easy to understand and easy to change. One way to do this is to organize the software as an easy to understand composition of easy to understand modular parts, and, furthermore, to base the structure of the software on the structure of the conceptual problem analysis. In our case, this means basing the software architecture on the decomposition of the problem into a sequence of transformations between representations.